Application software to be run on standard personal computers usually allows interaction with the user of the software by means of a graphical user interface (GUI). A GUI comprises graphical objects such as windows that display information and controls such as buttons or text boxes that are responsive to user commands such as mouse clicks and keyboard presses. The displayed information and labels on such controls are often in text format, comprising strings of characters in a particular alphabet making up words in a corresponding human language prevailing in the location where the application was developed. This presents a problem if the software is to be marketed in locations where the language of the original location is not widely understood. Clearly it would be excessively laborious to re-develop the application from scratch using a different language, and other location-specific features such as flag images, corresponding to each location where the software is to be marketed.
The conventional approach to this problem uses two steps, as illustrated in FIG. 4: the application developed in the original location (the “original application” 400) is first “internationalized” (410) by extracting from the GUI code the location-specific elements of the GUI such as text strings to a resource file 430, and replacing them in the “internationalized application” 420 with identifiers or references to the resource file. The internationalized application is then “localized” 440 by generating a localized resource file 460 from the resource file 430. The central activity of localization is language translation, but other activities may be required. At compilation time the resource identifiers in the internationalized application 420 are replaced by the corresponding translated resources in the localized resource file 460, resulting in a localized application 450 with an appropriately location-specific GUI.
Application software to be released to market must be rigorously tested for correctness and stability, and it is efficient to automate the process of testing as much as possible. The testing of localized software should include examining the GUI to ensure it is appropriately location-specific. Conventional approaches to testing the internationalization and localization (I&L) of software are almost completely manual. In addition to the time and expense of manual testing, manual testers could interpret I&L requirements differently, leading to variability in the tested product.